Problem

Code references below are pinned to main@46da678.

PeerConnectionTransport.trackBitrates is a plain mutableMapOf<...>() (a LinkedHashMap) with no thread-safety. Reads and writes on it race inside a single LocalParticipant.negotiate() call.

engine.createSenderTransceiver(...) causes WebRTC to fire onRenegotiationNeeded. That goes through PublisherTransportObserver.onRenegotiationNeeded() and engine.negotiatePublisher() into the 20ms-debounced negotiate field. When the debounce closes, createAndSendOffer iterates the map on the RTC thread via ensureCodecBitrates(...).

Still inside the same negotiate() body, engine.registerTrackBitrateInfo(...) writes to the map on the calling coroutine's thread. The auto-trigger is intentional and documented in LocalParticipant: "PublisherTransportObserver.onRenegotiationNeeded() gets triggered automatically so no need to call negotiate manually."

If the debounce closes while a put is still in flight, iteration on the RTC thread can throw ConcurrentModificationException from ensureCodecBitrates. Any publish path that hits this createSenderTransceiver then registerTrackBitrateInfo sequence is exposed (SVC video with a maxBitrateBps encoding).

Fix

Route both registerTrackBitrateInfo overloads through executeRTCIfNotClosed { ... } so writes share the single-threaded RTC executor with the read site. Same pattern as updateRTCConfig and addIceCandidate in the same class. The RTC thread already serves as the lock for peer-connection-adjacent state.

The closed-state guard inside executeRTCIfNotClosed also makes post-close calls silently drop, matching the surrounding APIs.

Scope

Independent of #823, which added a Mutex around createAndSendOffer for concurrent offer creation. That PR did not touch registerTrackBitrateInfo, so this race remained on main. No API or behavioral change for callers beyond the write going through the RTC executor.